Suspense Refunds

Suspense refund functionality is demonstrated in OIPA using client level activities. When a client level activity is processed in order to create a suspense refund, configuration is present to require that OIPA automatically generate a suspense refund number. The final piece of the process requires that a disbursement activity be processed to return the money to the client.

The SuspenseRefundDisbursement prototype demonstrates the configuration that can be used to accomplish this refund process.

Suspense

When the <Suspense> element is present in the transaction, a Suspense tab will be available on the Activity Details screen, which will contain a Suspense Number field, along with a Suspense Record search criteria and result sections. When the activity is processed, the suspense record selected to be fully or partially refunded, will be updated to reflect the refunded portion in the Attached column.

Disbursement

The transaction that triggers the refund may also contain a disbursement element.

Important: An alternate configuration is to spawn the disbursement from the activity when it is processed in OIPA.

The optional element <DisbursementClient> was added to the standard Disbursement configuration. The value of this element is the math variable or field that holds the ClientGUID. The <DisbursementClient> element will be ignored if present in the configuration of a policy level transaction. If <DisbursementClient> is not present in the client disbursement transaction configuration then a stack trace is thrown. The <DisbursementRole> element will be ignored if present in the client configuration.

The disbursement requires approval if the disbursement configuration of the transaction uses the Disbursement element attribute APPROVAL. This attribute allows for values of Yes and No. A Yes value indicates that the pending disbursement will be displayed in the Disbursement Approval screen. A value of No indicates that the pending disbursement will not be displayed in the Disbursement Approval screen.

When approval has been stipulated in the transaction disbursement configuration, the disbursement is written to AsDisbursementApproval with a status of Unapproved. Approval of the disbursement will write the Approval Date to this same table. Additionally, the status of the disbursement is changed to reflect Approved. Disapproval of the disbursement will write the Disbursement Disapproval Code to AsDisbursementApproval and change the disbursement status to Disapproved. On the Disbursement Approval screen, security for the OK button is based on security role.

Disbursement recovery for disbursements from a client activity will process exactly like disbursements from a policy level activity. Unlike recovery processing at a policy level where the shadowed disbursement for a RoleGUID on the policy is summed, for recovery processing on a client, the shadowed disbursements for the ClientGUID will be summed. A summing up of disbursements across different suspense numbers will take place when a client has multiple disbursements from different suspense numbers. This may result in a shadowed disbursement from Suspense 1 recovered from Suspense 2, for example.

High Level Steps to Set Up Suspense Refunds

The following list contains the major steps involved in setting up suspense refunds. Follow the links to find additional information on the steps involved in this process.

  1. Configure the transaction that will activate the refund. Refer to the prototype example for additional information on this transaction. Client level activities are typically used to generate suspense refunds.

  2. Configure the suspense refund number in the transaction.
  3. Configure the suspense section in the transaction.
  4. Configure the disbursement section in the transaction.